3. Discussion

The core issue for resource interoperability is enabling resource information, when encapsulated in, or transmitted with, an iCalendar object, to be viewed and understood in a manner that is actionable for the recipient. If the resource is a location, the recipient should be able find it; if a projector, learn its connectors and resolutions; if a piece of transport equipment, learn its carrying capacity and any certifications required for its operation, etc. This goal requires either that sufficient resource data be encapsulated within an iCalendar object or that a reference may be resolved to its canonical source.

Given these goals, our observations regarding the commonality of fields present in different recording systems, and the similarity between resource and user attributes, we looked to vCard as a mechanism for standardizing information for calendar resources. vCard and iCalendar have many similarities in their structured representation of localized data and data types, and they may prove highly compatible for resources as well as traditional users.

The congruence between vCard and iCalendar, and the loci that provide the possibility on which our recommendation is based, are found in the attributes of the ATTENDEE iCalendar property (see Appendixes D and E for the relevant sections of the Calsify and vCard drafts):

• We observe that an attribute of the ATTENDEE property is DIR. DIR is similar to vCard’s SOURCE attribute in that both store a URI value that points to a directory entry.

• We observe also that iCalendar CUTYPE and vCard KIND play similar roles, being the classification of records in order to differentiate standard users from other types (e.g. group, organization). If there were direct mapping between their possible values, it would be possible to standardize the representation of resource information in vCard objects.

CUTYPE valuesKIND ValuesINDIVIDUAL*individual*GROUPgroupRESOURCE-ROOMUNKNOWN--
orgx-namex-nameiana-tokeniana-token
* indicates default value

We thus have a remarkable congruence between the current iCalendar specification for the attributes of an ATTENDEE and the two vCard properties SOURCE and KIND:

We observe, but have not met, a pragmatic need for additional metadata pursuant to resources. We observe that implementations leave the ResourceName field as an open text string. Customers may or may not have tools to classify their resources according to classes of local import. (e.g., cart, projector, dolly, laptop). We believe this area is ripe for improvement, perhaps in a series of customer-extensible key/value pairs, with population thereof and sorting exposed in the calendar user agents. Ideally, this information could also be encapsulated within an iCalendar object and available to external recipients.